Add Book to My BookshelfPurchase This Book Online

Chapter 8 - Troubleshooting

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

A General Troubleshooting Blueprint
One of the best math tutors I ever had gave me some simple but effective advice. He said that before I try to solve a problem, I should write down what I have to find out and what information I have to work with. This advice carries over to troubleshooting internetwork problems as well, i.e., if you can get a clear definition of what you are trying to do and gather appropriate information on the problem, you are well on the way to solving the problem.
When solving mathematics problems, all the information needed generally is presented to you, but when solving internetwork problems you have to get the information yourself. Cisco makes this as straightforward as it can be by extensive show and debug commands. You, however, must know which of these commands to use in a given situation in order to get the information you need. Therein lies the art.
Internetwork problems generally fall into one of the following categories:
  1. A Physical layer issue with device interconnection, hardware, or line failure.
  2. A Data Link layer issue involving configuration of internetwork device interfaces.
  3. A Network layer issue with network protocol configuration or operation.
  4. Performance or traffic congestion problems causing Transport layer timeouts.
  5. A software bug either in the application using the internetwork, or within the Cisco IOS itself.
The first four points follow the first four layers of the ISO data communications model, starting at layer 1, the Physical level. The fifth point covers all issues that arise in the top three layers of the ISO model. This is generally the way I recommend people start to troubleshoot internetwork problems. Start from the Physical layer and work upward. It may not always work out so neatly that you can pinpoint an internetwork problem as being sourced within one layer's operation, but checking the operation of protocols on a layer-by-layer basis will give you a good view of how the problem manifests itself.
Before reviewing the simple troubleshooting scenario explored in Chap. 3, there is one more point to consider before you rush in to fix things. In many cases, it is very simple to make the situation drastically worse. By rushing in and changing the configuration of devices on an internetwork, problems can occur that make the original situation seem like Nirvana. The next two points always should be at the forefront of your mind when you're troubleshooting:
  1. Only change one variable at a time and observe the effect this has on the problem.
  2. Always but always, and without exception, have a means of backing out of the change you are about to make.
There are a few other subtleties to consider, such as the effect on the processing power that issuing a given debugging command will have, but we will cover these on a case-by-case basis when we examine examples. If you adhere to the aforementioned two guidelines, you should be in good shape, and will probably not turn a problem into a crisis.
I will not examine the use of third-party devices such as LAN or WAN analyzers, although there are many excellent products on the market that will help you. In the main, the tools provided by Cisco are adequate to troubleshoot the vast majority of problems encountered. If you master all that Cisco offers you, however, by all means explore third-party devices.

 


 
Books24x7.com, Inc © 2000 –  Feedback